Intelligent telecommunications networks have engendered a number of new and interesting services for telecommunications subscribers. Call routing, calling card checks, call screening, and identifying callers are some of the services which may now be supported by intelligent networks. The intelligent networks also now permit real time creation and modification of customized features and services desired by particular subscribers. An example is Personal Number Calling, in which a person may request that she or he be reached at one location for particular times of the day and at another location for other times, all using the same telephone number, but subject to change immediately.
Intelligent networks are well suited to address these new additional demands flexibly, efficiently and reliably. Information relating to the status of services and features desired by subscribers may be maintained in intelligent Network Elements ("NEs") such as conventional Advanced Intelligent Network ("AIN") Service Control Points ("SCPs"), Service Nodes ("SNs"), other Intelligent Peripherals ("IPs"), or other intelligent network elements which are available for query by central offices, switches and similar elements of the telecommunications switching network. Such subscribers may be those who subscribe to telecommunications, cable or television programming, multimedia or other services which may be provided on any information infrastructure, regardless of nature or bandwidth.
According to certain BellSouth Telecommunications intelligent network architecture, for a conventional example, data corresponding to the status of services and features for particular subscribers in a Personal Number Calling context may be stored in certain applications contained in Service Control Points. Appropriate logic in a Service Node is invoked by a call from a particular subscriber who wishes to make a change to her or his subscriber changeable data. The Service Node logic verifies the data from the subscriber and routes an update message to the appropriate Service Control Point that contains the subscriber's data. The logic provides verification to the subscriber if the update is a success and then continues call processing. If the update fails, the logic may attempt to update a second time which, if unsuccessful, results in denying the change to the subscriber and terminating the call.
For a number of reasons, it is desirable to maintain concurrent, redundant data corresponding to the same subscriber but resident on different machines and even at different geographical sites. In BellSouth Telecommunications intelligent networks for instance, there are at least two databases which store data for a particular subscriber. Each database resides in a different Service Control Point, and the Service Control Points are sometimes located geographically remotely from each other. (Each of the Service Control Points also preferably contains a parallel set of data mirrored locally/internally in conventional fashion on tandem devices.) The redundancy offered by these mated Service Control Point helps cover the unavoidable system failures and maintenance periods, but it also allows load sharing among Service Control Points as well as the capacity to designate active or standby Service Control Points in an effort to distribute the load across the network.
The conspicuous and primary disadvantage of such redundant databases is that they will inevitably fail to contain the same data at some point for reasons which are limited only by the imagination. For instance, during subscriber changeable data updating efforts, a particular relevant Service Control Point may be out of service or communications links may be lost. Data concurrence must obviously be restored quickly in such case, and in any event before the Service Control Point resumes call processing.
Even if platform or communications failures are discounted or ignored, reconciliation between the databases must occur in real time and reliably, since calls may be processed by either Service Control Point at any time depending on management and control of the network. Subscriber services such as Personal Number Calling only exacerbate this requirement, since, for example, a subscriber who is entering a change may be walking out the door and expecting calls in her car in the next few minutes.
Other conventional techniques for updating parallel databases such as those found in remotely located Service Control Points include communicating the update information simultaneously to the databases. Such techniques typically address the data reconciliation or synchronization issue with "audit" software in every application that corresponds to each set of subscriber data. This audit software seeks to synchronize subscriber changeable data between the mated databases by, among other things, recording information relating to any data for which an update failure occurs by reason of failure to synchronize with other applications, link failures, out-of-service conditions, or otherwise. If the software is unable to synchronize the data, it sets a "data audit" timer and attempts to synchronize again when the timer expires.
Primary among the issues created by this "audit" approach is that execution of the audit degrades system performance by dissipating processor capacity and other resources which could otherwise be employed to process calls (since the update messages have the same priority, typically, of any call processing messages). Additionally, the appropriate software must be included in each application that shares synchronous data with a mate and it thus wastes memory.
As an example, if an application in a first Service Control Point is rendered out of service, its mate, a service application in a second Service Control Point, may receive new subscriber changeable data (such as Personal Identification Numbers or Call Rejection Lists). Conventionally, when the first service application is restored, the Service Control Point automatically sends a signal to the appropriate Signal Transfer Point ("STP") that the SubSystem Number ("SSN") associated with the restored application is "allowed." Allowance of the SSN causes the Signal Transfer Point immediately to begin routing pending queries to the newly restored application. This unfortunately can occur before the application data has been updated with subscriber changeable data corresponding to the period in which the application or SCP was out of service. Conventional resolution of this problem involves entering a maintenance message at the Signal Transfer Point level which inhibits the SSN of the application that is in the restore process. This solution unfortunately involves coordination of at least two maintenance organizations and can in any event allow service call queries inadvertently to reach the service application after it has been restored and the SSN allowed, but before the STP has taken the SSN out of service.
Additionally, when an SSN is currently inhibited via the Service Control Point maintenance terminal for audit purposes, its assigned application is also taken out of service unless the application is designated with multiple SSNs (which can present other problems). It may also unfortunately be the case that the service application SSN must be active in order to communicate with the intelligent network, so that the application cannot be updated when it is supposedly being brought current through the audit process. Therefore, inhibition of a service application's SSN through the Service Control Point maintenance terminal during conventional update audit can unnecessarily prevent the application from completing data synchronization.
An interim solution is to utilize a Service Control Point maintenance message that allows the service application SSN to be inhibited from the call processing perspective (such as vis avis the STP) but which does not render the application out of service for other purposes such as synchronization through the audit process before final SSN restoration via X.25 links. This approach allows necessary maintenance commands to be entered from the Service Control Point maintenance terminal, X.25 communication to synchronize new subscriber changeable data, and a narrower opportunity for queries inadvertently to reach the unsynchronized application before it is taken out of service for audit purposes. The application may subsequently be restored to active status at the STP level. This data concurrence process is cumbersome at best, however, and its efficacy will erode even further as the network supplied services and subscriber bases proliferate and become more multivalent.
Conventional approaches to data concurrence accordingly fail adequately to address multiple needs associated with updating and reconciling redundant databases in mated Network Elements and applications reliably, efficiently, quickly and with a minimum of management and coordination.